1. Field
The system and method relates generally to management of a single database accessible over a network by multiple unique entities and particularly to data entry into a single database accessible a unique entity, and each unique entity defines unique database data criteria.
2. Description of the Problem and Related Art
Databases for storing vast amounts of information are ubiquitous, and are created, populated, and modified constantly, typically through a network of computer-based devices. Databases typically providing information in response to a user query and compiled from data entered into the database.
One example is a web-accessible Multiple Listing Service (“MLS”) that comprises a database of real property for sale in a given geographic area and may be queried by real estate brokers, agents, buyers or sellers, to find information relating to such property. Such information includes, the type of property, whether commercial, residential, unimproved land, rental, condominium, or detached house, etc., the approximate area of the property or within any structure on the property (e.g, the approximate square footage with the living spaces of a house or condo), the number of rooms in a house, the number of bedrooms/bathrooms, the types of rooms (e.g., den, kitchen, living room, etc.), room dimensions, asking price, amenities, seller conditions, school/political district, and even photographic images of the property. Typically, an MLS listing properties for sale in a given geographic region is proprietary to a real estate professional organization, or realtor association, associated with that geographic region. For example, the MLS covering properties for sale in Charlotte, N.C., is controlled by the Charlotte Regional Realtor Association, and San Diego Association of Realtors controls the MLS for San Diego, Calif.
Conventionally, each MLS is maintained in a self-contained, stand alone database and data corresponding to property listings is entered by real estate brokers, real estate agents, or other users acting on their behalf, with association-sanctioned authority to enter such data. MLS databases are conventionally created by companies that provide MLS database programming and maintenance services. However, usually such companies have to create, and manage an individual, stand-alone database for each realty association. The population of data into each database must be constructed individually.
Efforts to unite MLS databases have been underway by such database service companies to create a single master database comprising the multiple individual MLS databases, in order to reduce the time, cost and complexity of multiple database management. However, a major obstacle to this effort has been, until now, that each realty association has differing criteria for the data that may be entered into its respective MLS. Such criteria may be defined by the association itself, or may be required by municipal, state statute or regulation, or required by other governing bodies. Such criteria may include the type of data that may entered into an MLS listing, or the values that may be entered. In other words, individual associations have myriad different rules, making the creation or maintenance of a single database of multiple MLS's tedious, if not infeasible.
Rules engines, or expert systems, have evolved to construe requests for information and to provide information stored in a knowledge according to a set of rules that determine what information is relevant to the request. Typically, rules engines access a data structure comprised of rules that consist of data or information, and, in response to a query from a user, the rules engine calls and executes the relevant rule, or rules, which are essentially computer programs containing logical syllogisms that govern the retrieval and return of information in response to the query. One obvious example of such a rules engine is an internet search engine. Another example is found in U.S. Pat. No. 5,826,250, by Trefler, teaches a rules database for retrieving data in response to a query where the database is configured with separate records with fields for a data objective, e.g., “loan rate”, one or more circumstances in which to apply a rule and one or more rules applicable to a given circumstance that meets the data objective. In this situation, rules may differ depending on circumstance, e.g., by geographic area. The record includes a field that indicates whether the rule is valid for the circumstance in which the record is called, or whether a record is “inherited” or whether there is another record that defines a rule that also applies. Accordingly, for a rules engine to navigate this database, it must parse a record and if another record is indicated it must then search for the “ancestral” or superior record. While this database may comprise different rules associated with different “circumstances”, it suffers from the obvious shortcoming that each record must be coded and maintained not only to apply the correct rule, but to insure that the required hierarchy of circumstances is maintained. In a case in which different entities define different rules, this becomes so cumbersome as to be infeasible. Moreover, such a database design requires a large amount of memory, and accordingly lacks scalability to encompass multiple sets of circumstances.
Other rules engines have been developed to validate access rights to a network application or database, as taught in U.S. Pat. No. 6,163,844, to Duncan, et al., and U.S. Pat. No. 7,984,513, to Kyne, et al. Another system, disclosed in U.S. Pat. No. 8,103,607, to Schneider, uses a rules engine to choose and execute auxiliary programming functions that apply to one or more core functions of an executed application.
None of these solutions, however, address the problem of entering into and maintaining data in a common database where criteria governing acceptable data types and values vary depending on the entity accessing the database. Data entry for single databases for a single entity is currently validated according to a rules engine, typified by the familiar instance of registering for some account online wherein the user is warned and prevented from registration if the user fails to enter data into a required field. Again, however, these instances apply to a single entity governing a single database. Governing data entry into a single database where the data is entered by users associated with different entities whose data requirements are varied has heretofore been too complex to render a feasible solution.